Vulnerability Remediation

The time has come to remediate the vulnerabilities that we found over the course of this project. To recap, we have scanned our vulnerable Windows 10 VM from both vantage points that the Qualys vulnerability management platform offers. We scanned our target with the Qualys scanner appliance and found open ports and misconfigured services running on those ports. We also scanned our target using the Qualys cloud agent. The cloud agent provided to us with more detailed information about apps installed on the OS, system configuration issues, and missing patches. It also provided some of the same information about open ports and misconfigured service. The next step in the process is remediation.

Again, here are the read outs from both scanning methods. Qualys Scanner Appliance Results

Qualys Cloud Agent Results

Note: In the photo above we can see that 7 vulnerabilities were fixed, this was due to the outdated version of Google Chrome auto-updating to the latest version.

Removing Outdated Apps

Digging into the results of the cloud agent scan, we can see that the majority of the severity 5 vulnerabilities are coming from the outdated version of Firefox that we installed on our Windows 10 VM. In order to remediate these issues with outdated apps we either need to update them or flat out uninstall them, which is the course of action that I am going to take.

Previously we took some snapshots of the Windows 10 VM, which is great as if we further need to test out Qualys scanning, we can always revert the machine back to it's vulnerable state and continue testing.

Then, by logging into our Windows 10 VM and checking the installed apps, we can confirm that Firefox 18.0.1 is installed. I proceeded to remove Firefox and all the other old apps that we installed for the purposes of this lab.

To recap the list of vulnerable software that was installed on the machine, that has now been removed is as follows:

• VLC Media Player 0.9.8
• Mozilla Firefox 18.0.1
• Google Chrome 24.0.1312.57
• VirtualBox 4.2.18
• PuTTY 0.59

Now that they are uninstalled, let's push an on-demand scan task to the cloud agent. From the Qualys cloud agent section of the dashboard, we click on the entry for our Windows VM, and from the drop down we select On Demand Scan.

Select the type of scan that is to be run, in our case for this project, I have selected the option for Vulnerability Scan.

After the cloud agent finished the on demand scan, I checked for reported vulnerabilities on the machine. We no longer have any severity 5 issues related to any of the applications that we purposely installed, we also now only have 6 active vulnerabilities being reported with, 267 vulnerabilities fixed. Lets continue on an see what we have left to remediate.

Looking now at the remaining vulnerabilities, let's tackle them by severity, which is how security professionals in the real would would prioritize and address these issues. We have one severity 4 vulnerability. Checking the details it shows the following:

WinVerify Trust Signature Validation

Okay, so we have a vulnerability relate to Microsoft WinVerify Trust Signature Validation. Clicking on the details of the vulnerability, Qualys provides useful information about the vulnerability. The details include the CVE ID of the vulnerability, if there is a patch available for it, compliance related info, and detection logic for how the cloud agent scans for and confirms the vulnerability.

It looks like our cloud agent checks for the presence of two regkeys HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config and also HKEY_LOCAL_MACHINE\Wow6432Node\Software\Microsoft\Cryptography\Wintrust\Config.

Digging into the CVE information via the link provided in the details, it looks like this vulnerability was a republication of another CVE for the same issue. Microsoft republished the CVE as it does not plan to enforce the stricter method of signature verification EnableCertPaddingCheck on it's current versions of Windows 10 & 11.

The vulnerability itself is a flaw that is present in the way in which the Windows OS function, WinVerify Trust, handles Authenticode signature validation. This is done for (PE) Portable Executable files. The flaw allows for threat actors to pad an already verified PE file, enabling malicious code to execute, allowing the possibility of complete take over of the target system. This is all done without invalidating the file's trust signature. The attack vectors for this type of vulnerability are numerous due to the fact that all you have to do is have an unsuspecting user execute the file.

Remediation

So, now we know what this vulnerability is, it's scope of impact on our VM, which is significant, lets us now look to remediate this vulnerability. Qualys has a tab on the vulnerability report for solutions to reported vulnerabilities.

The information in the solution tab gives us much of the same information present on the URL provided for the CVE. The link in the solutions page though, points to Microsoft's official information for the vulnerability. Scrolling down to toward the bottom of that page, we can see steps for remediation.

We have to go into the Windows registry and modify two registry key entries, which are the two I mentioned from the detection logic that Qualys was using to detect the vulnerability in the first place.

Launching back into our Windows VM. I opened up Regedit as admin and proceeded to make the needed changes to the two registry keys. The first of which was HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config. When I navigated to the path I did not find a registry key, so I went ahead and created it and added the DWORD EnableCertPaddingCheck, giving it a value of 1.

I then did the same for HKEY_LOCAL_MACHINE\Wow6432Node\Software\Microsoft\Cryptography\Wintrust\Config and rebooted the machine, as the Microsoft documentation states.

I then initiated an on demand scan of the VM from the Qualys dashboard. It has updated and now the vulnerability is no longer present on the machine. Vulnerability remediated!

Allowed Null Sessions

Moving down the list of vulnerabilities present The next item on the list is a Sev 3 vulnerability about having Windows configured to Allow Null Sessions. The vulnerability is related to two CVEs, namely CVE-2002-1117 and CVE-2000-1200. The first CVE, CVE-2002-1117, details that the software Veritas Backup Exec requires that Microsoft Exchange 2000 servers are required to have the regkey RestrictAnonymous set to a value of 0 for it to function correctly, leaving the target server vulnerable. CVE-2000-1200 details that with Null sessions allowed, on domain joined windows computers, a threat actor could enumerate all users currently on the domain. This is done via obtaining of the domains SID via the use of the LsaQueryInformationPolicy function when in the null session.

Remediation

Now that we have educated ourselves on the vulnerability and what impact in can have on an organizations environment, we need to remediate it. The CVE listings presented by Qualys provided useful information but, not a way to resolve the issue.

Qualys as a platform does provide a solution tab to explore that should point us in the correct direction for remediation.

The above is the solution tab for the vulnerability we are looking to remediate. We are pointed to two documentation pages from Microsoft on the RestrictNullSessAccess and RestrictAnonymous settings.

Clicking on the link for the RestrictNullSessAccess and reading through the documentation, we can see that we have to go into the Windows registry and add the key RestrictNullSessAccess to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters and setting it to a value of 1.

The second link for RestrictAnonymous explains the best practice of not allowing anonymous SAM accounts and shares, also the related group policy to enable/disable this setting. The Qualys vulnerability details also explain that scanners look for the presence of the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA RestrictAnonymous, which controls this setting. If it is not their then the system is vulnerable.

Proceeding on with this information I proceeded to push the configuration changes to our virtual machine for remediation.

I proceeded to open regedit as admin and navigate to the first registry entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Paraemters. As you can see we have the needed option/regkey present, which is RestrictNullSessAccess but, the value is set to 0.

At Qualys' recommendation I will enable the restriction by changing the regkey value to 1, restricting null session access on the machine.

Moving ahead to the second regkey we need to change, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA, I confirmed that on the machine the needed option/regkey, RestrictAnomymous was present but, had a value of 0. I enabled the setting, changing the regkey value to 1.

After the changes to the registry keys were complete, I went ahead and initiated an on-demand scan of the machine via the Qualys dashboard and waited for it to complete. After about an hour, I checked the status of the VM in Qualys and found that the vulnerability was remediated and no longer detected by Qualys.

SMB Signing Disabled

Moving on to the next vulnerability found, we have an entry for SMB signing being disabled.

Using the same methodology that we have used in previous remediations, I checked Qualys details of the vulnerability and the recommended method for remediation.

SMB signing is a function that provides and extra layer of security for SMB share access, thwarting man-in-the-middle attacks. It works via digitally signing SMB packets, leveraging Kerberos and NTLM in the process.

Reading through the Microsoft Documentation Qualys recommended, I found that we need to change the following group policy settings;

• Computer Configurations > Windows Settings > Security Settings > Local Policies > Security Options in here there are two settings. Microsoft network client: Digitally Sign Comminications (always) | Set to Enabled.
• Computer Configurations > Windows Settings > Security Settings > Local Policies > Security Options in here there are two settings. Microsoft network server: Digitally Sign Comminications (always) | Set to Enabled.

Now that we have the needed information to remediate the vulnerability, we can go ahead and enable the necessary group policy settings. I did this, following this up with a push of an on-demand vulnerability scan on the target VM.

And as you can see from the above, we can confirm that the vulnerability has been remediated. We no longer have a Sev 3 vulnerability related to SMB signing.

Birthday Attacks Against TLS (Sweet32)

This is our last confirmed vulnerability found on the our vulnerable virtual machine. The vulnerability affects TLS and is due in part to the configuration of ciphers used for the protocol. We have to re-configure Windows to make use of more modern secure ciphers. Lets take a look at the threat details to gather some insights.

Okay so, legacy block ciphers that use a blocks of 64 bits are vulnerable, this includes DES, 3DES, IDEA, and RC2. The way Qualys checks and confirms the vulnerability is via checking the presence of HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002 and checking it's value.

The solution section provides some documentation on the Sweet32 attack, Windows TLS changes, and Microsoft TLS Registry settings. Focusing on the Windows TLS changes page and ready through the content, we need to remove the entry for DES/3DES from the cipher suite functions registry key located at, HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002, which will disable usage of this old cryptography method.

Here we are at the registry location looking at the values of the function key. We can see that 3DES is in the list, specifically TLS_RDA_WITH_3DES_EDE_CBC_SHA. 3DES was on the list of encryption standards that were included in the vulnerability details. Lets go ahead and remove that entry to disable the usage of that cipher suite.

I then rebooted the Windows VM and initiated an on-demand scan from the Qualys dashboard. After the scan was run, the Qualys dashboard confirmed that the vulnerability was remediated. We no longer have a Sev 4 entry for Birthday Attacks (Sweet32).

Curl Exposure CVE-2025-0167

At the time of this projects writing, there was discovered and vulnerability affecting a subset of version of the curl cli tool. During investigation of this CVE, I found that there was no clear way to mitigate the vulnerability directly on Windows. Curl is a integral part of the Windows OS so remediation guidance has to be provided by Microsoft, either in the form of a system update or possibly some registry or group policy settings.

In the case that the CVE details are updated to include remediation steps or an update is issued by Microsoft, I will update this project with steps taken for remediation.